Providing data authorization based on blockchain

ABSTRACT

Disclosed herein are methods, systems, and apparatus, including computer programs encoded on computer storage media, for providing blockchain-based data authorization. One of the methods includes receiving, by a blockchain node, a data acquisition transaction submitted by a data user for obtaining target data possessed by a data owner, determining, by the blockchain node, that the data user has obtained authorization of the target data, and executing, by the blockchain node, a smart contract invoked by the data acquisition transaction to provide one or more of the target data and a computational result of one or more predetermined computational operations performed based on the target data to the data user.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims the benefit of priorityof U.S. patent application Ser. No. 16/779,228, filed Jan. 31, 2020,which is a continuation of PCT Application No. PCT/CN2020/072038, filedon Jan. 14, 2020, which claims priority to Chinese Patent ApplicationNo. 201910704682.7, filed on Jul. 31, 2019, and each application ishereby incorporated by reference in its entirety.

TECHNICAL FIELD

One or more implementations of the present specification relate to thefield of blockchain technologies, and in particular, to a smartcontract-based data authorization method and apparatus.

BACKGROUND

A blockchain technology (also referred to as a distributed ledgertechnology) is a decentralized distributed database technology, and ischaracterized by decentralization, openness and transparency,tamper-resistance, trustworthiness, etc., and therefore, is applicableto many application scenarios that require high data reliability.

SUMMARY

In view of this, one or more implementations of the presentspecification provide a smart contract-based data authorization methodand apparatus.

To achieve the previous objective, one or more implementations of thepresent specification provide the following technical solutions:

According to a first aspect of one or more implementations of thepresent specification, a smart contract-based data authorization methodis provided, and includes the following: receiving, by a blockchainnode, a data acquisition transaction submitted by a data user, where thedata acquisition transaction is used to request to obtain target dataheld by a data owner; and executing, by the blockchain node, a dataauthorization smart contract invoked to perform the data acquisitiontransaction, where the data authorization smart contract is used toobtain the target data when it is confirmed that the data user isauthorized, so that the data user obtains at least one of the targetdata and an operation result obtained after a predetermined operation isperformed on the target data.

According to a second aspect of one or more implementations of thepresent specification, a smart contract-based data authorizationapparatus is provided, and includes the following: a receiving unit,configured to enable a blockchain node to receive a data acquisitiontransaction submitted by a data user, where the data acquisitiontransaction is used to request to obtain target data held by a dataowner; and an execution unit, configured to enable the blockchain nodeto execute a data authorization smart contract invoked to perform thedata acquisition transaction, where the data authorization smartcontract is used to obtain the target data when it is confirmed that thedata user is authorized, so that the data user obtains at least one ofthe target data and an operation result obtained after a predeterminedoperation is performed on the target data.

According to a third aspect of one or more implementations of thepresent specification, an electronic device is provided, and includesthe following: a processor; and a memory, configured to store aninstruction that can be executed by the processor, where the processorruns the executable instruction to implement the method according to thefirst aspect.

According to a fourth aspect of one or more implementations of thepresent specification, a computer-readable storage medium is provided,where the computer-readable storage medium stores a computerinstruction, and when the instruction is executed by a processor, thesteps in the method according to the first aspect are implemented.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a schematic diagram illustrating an example environment,according to an example implementation;

FIG. 2 is a schematic diagram illustrating a concept framework,according to an example implementation;

FIG. 3 is a flowchart illustrating a smart contract-based dataauthorization method, according to an example implementation;

FIG. 4 is a schematic diagram illustrating end-to-end data authorizationimplemented based on a blockchain network, according to an exampleimplementation;

FIG. 5 is an interaction flowchart illustrating end-to-end dataauthorization implemented based on a blockchain network, according to anexample implementation;

FIG. 6 is a schematic structural diagram illustrating a device,according to an example implementation;

FIG. 7 is a block diagram illustrating a smart contract-based dataauthorization apparatus, according to an example implementation.

DESCRIPTION OF IMPLEMENTATIONS

Example implementations are described in detail here, and examples ofthe example implementations are presented in the accompanying drawings.When the following description relates to the accompanying drawings,unless specified otherwise, same numbers in different accompanyingdrawings represent same or similar elements. Implementations describedbelow do not represent all implementations consistent with one or moreimplementations of the present specification. On the contrary, theimplementations are only examples of apparatuses and methods that aredescribed in the appended claims in detail and consistent with someaspects of one or more implementations of the present specification.

It is worthwhile to note that in other implementations, steps of acorresponding method are not necessarily performed according to thesequence shown and described in the present specification. In some otherimplementations, the method can include more or less steps than thosedescribed in the present specification. In addition, an individual stepdescribed in the present specification can be divided into a pluralityof steps in other implementations for description. However, a pluralityof steps described in the present specification can also be combinedinto a single step for description in other implementations.

FIG. 1 is a schematic diagram illustrating an example environment,according to an example implementation. As shown in FIG. 1, an entity isallowed to participate in a blockchain network 102 in an exampleenvironment 100. The blockchain network 102 can be a public blockchainnetwork, a private blockchain network, or a consortium blockchainnetwork. The example environment 100 can include computing devices 104,106, 108, 110, and 112, and a network 114. In an implementation, thenetwork 114 can include a local area network (LAN), a wide area network(WAN), the Internet, or a combination of LAN, WAN and Internet, and isconnected to a website, user equipment (e.g., a computing device), and abackend system. In an implementation, the network 114 can be accessedthrough at least one of wired communication or wireless communication.

In some situations, the computing devices 106 and 108 can be nodes (notshown) in a cloud computing system, or each of the computing devices 106and 108 can be a standalone cloud computing system, including aplurality of computers interconnected through a network and operating asa distributed processing system.

In an implementation, the computing devices 104 to 108 can run anysuitable computing system, so as to serve as nodes in the blockchainnetwork 102. For example, the computing devices 104 to 108 can includebut are not limited to a server, a desktop computer, a notebookcomputer, a tablet, and a smartphone. In an implementation, thecomputing devices 104 to 108 can belong to a related entity and areconfigured to implement a corresponding service. For example, theservice can be used to manage a transaction of one entity or atransaction between a plurality of entities.

In an implementation, each of the computing devices 104 to 108 stores ablockchain ledger corresponding to the blockchain network 102. Thecomputing device 104 can be (or include) a network server configured toprovide a browser function, and the network server can provide visualinformation related to the blockchain network 102 based on the network114. In some situations, the computing device 104 may not participate inblock verification, but monitor the blockchain network 102 to determinewhen other nodes (e.g., the computing devices 106 and 108) reach aconsensus, and therefore, generate a corresponding blockchain visualuser page if other nodes reach a consensus.

In an implementation, the computing device 104 can receive a requestfrom a client device (e.g., the computing device 110 or the computingdevice 112) for the blockchain visual user page. In some situations, anode in the blockchain network 102 can also serve as a client device.For example, a user of the computing device 108 can send the request tothe computing device 104 by using a browser running on the computingdevice 108.

In response to the request, the computing device 104 can generate theblockchain visual user page (e.g., a webpage) based on the storedblockchain ledger, and send the blockchain visual user page generated tothe requesting client device. If the blockchain network 102 is a privateblockchain network or a consortium blockchain network, the request forthe blockchain visual user page can include user authorizationinformation. Before generating the blockchain visual user page andsending the blockchain visual user page to the requesting client device,the computing device 104 can perform verification on the userauthorization information, and return the corresponding blockchainvisual user page after the verification succeeds.

The blockchain visual user page can be displayed on the client device(e.g., a user interface 116 shown in FIG. 1). When the blockchain ledgeris updated, display content on the user interface 116 can be updatedaccordingly. In addition, interaction between the user and the userinterface 116 can result in a request for another user interface, forexample, displaying a block list, block details, a transaction list,transaction details, an account list, account details, a contract list,contract details, or a search result page generated after the usersearches the blockchain network.

FIG. 2 is a schematic diagram illustrating a concept framework,according to an example implementation. As shown in FIG. 2, the conceptframework 200 includes an entity layer 202, a hosting service layer 204,and a blockchain network layer 206. For example, the entity layer 202can include three entities: an entity 1, an entity 2, and an entity 3,and each entity has its own transaction management system 208.

In an implementation, the hosting service layer 204 can include aninterface 210 corresponding to each transaction management system 208.For example, each transaction management system 208 communicates withthe corresponding interface 210 over a network (e.g., the network 114 inFIG. 1) using a protocol (e.g., Hypertext Transfer Protocol Secure(HTTPS)). In some examples, each interface 210 can provide acommunication connection between a transaction management system 208corresponding to each interface and the blockchain network layer 206.More specifically, the interface 210 can communicate with a blockchainnetwork 212 of the blockchain network layer 206. In some examples,communication between the interface 210 and the blockchain network layer206 can be implemented through remote procedure calls (RPCs). In someexamples, the interface 210 can provide an API interface to thetransaction management system 208 for accessing the blockchain network212.

As described here, the blockchain network 212 is provided in the form ofan equalized network including a plurality of nodes 214. Each of thenodes 214 is respectively configured to permanently store a blockchainledger 216 formed by blockchain data. FIG. 2 shows only one blockchainledger 216, but a plurality of blockchain ledgers 216 or copies thereofcan exist in the blockchain network 212. For example, each node 214 canmaintain one blockchain ledger 216 or a copy thereof.

It is worthwhile to note that a transaction described in the presentspecification refers to data that is created by a user by using a clientof a blockchain network and needs to be finally published to adistributed database of the blockchain network. Transactions in theblockchain include a transaction in a narrow sense and a transaction ina broad sense. The transaction in the narrow sense refers to a valuetransfer published by a user in the blockchain. For example, in aconventional bitcoin blockchain network, the transaction can be atransfer initiated by the user in the blockchain. The transaction in thebroad sense refers to service data with a service intention that ispublished by a user in the blockchain. For example, an operator cancreate a consortium blockchain based on an actual service need, anddeploy some other types of online services (e.g., a rental service, avehicle scheduling service, an insurance claim service, a creditservice, and a medical service) that are not related to a value transferin the consortium blockchain. In such a consortium blockchain, thetransaction can be a service message or a service request with a serviceintention that is published by a user in the consortium blockchain.

Generally, there are three types of blockchains: a public blockchain, aprivate blockchain, and a consortium blockchain. In addition, there is acombination of a plurality of types, for example, a private blockchain+aconsortium blockchain, or a consortium blockchain+a public blockchain.The public blockchain has the highest degree of decentralization. Abitcoin blockchain and an Ethereum blockchain are representatives of thepublic blockchain. Participants of the public blockchain can read datarecords in the blockchain, participate in transactions, compete foraccounting rights of new blocks, etc. Furthermore, each participant(i.e., node) can freely join and exit the network and perform relatedoperations. On the contrary, writing permission of the privateblockchain network is controlled by a certain organization or agency,and data reading permission is specified by the organization. Briefly,the private blockchain network can be a weakly centralized system, astrict restriction is imposed on participating nodes, and there are afew participating nodes. This type of blockchain is more suitable foruse within a specified organization. The consortium blockchain is ablockchain between the public blockchain and the private blockchain, andcan implement “partial decentralization”. Each node in the consortiumblockchain network usually has a corresponding organization.Participants join the network through authorization and form aninterest-related consortium to jointly maintain operations of theblockchain network.

The public blockchain network, the private blockchain network, and theconsortium blockchain network can provide a function of a smartcontract. A smart contract in a blockchain network is a contract thatcan be triggered by a transaction in the blockchain system. The smartcontract can be defined in a form of code.

Taking Ethereum as an example, a user can create and invoke some complexlogic in the Ethereum network, which is the biggest challenge ofEthereum different from the bitcoin blockchain technology. As aprogrammable blockchain, the core of Ethereum is an Ethereum virtualmachine (EVM), and each Ethereum node can run the EVM. The EVM is aTuring-complete virtual machine, through which various types of complexlogic can be implemented. The smart contract published or invoked by auser in Ethereum can be run by the EVM.

However, in the technical solutions of the present specification, asmart contract is published and invoked on a blockchain node, so thatsecure end-to-end data authorization can be implemented between a dataowner and a data user. The following describes the technical solutionsof the present specification with reference to implementations.

FIG. 3 is a flowchart illustrating a smart contract-based dataauthorization method, according to an example implementation. As shownin FIG. 3, the method is applied to a blockchain node and can includethe following steps:

Step 302: A blockchain node receives a data acquisition transactionsubmitted by a data user, where the data acquisition transaction is usedto request to obtain target data held by a data owner.

The data user can directly generate the data acquisition transaction onthe blockchain node. Or, the data user can generate the data acquisitiontransaction on a client, and send the data acquisition transaction tothe blockchain node by using the client. Or, after generating the dataacquisition transaction on a client, the data user can send the dataacquisition transaction to another blockchain node, and the anotherblockchain node sends the data acquisition transaction to the blockchainnode. Certainly, after a consensus on the data acquisition transactionis reached, the data acquisition transaction is transmitted to eachblockchain node in the blockchain network, and each blockchain nodeexecutes the data acquisition transaction.

Generally, in a blockchain network using consensus algorithms such asproof of work (POW), proof of stake (POS), and delegated proof of stake(DPOS), nodes that compete for an accounting right can execute ablockchain transaction after receiving the blockchain transaction. Oneof the nodes that compete for the accounting rights may win in thecurrent round, and becomes an accounting node. Using the previous dataacquisition transaction as an example, the accounting node can pack thedata acquisition transaction with other transactions to generate a newblock, and send the new block generated to other nodes for consensus.

In a blockchain network using mechanisms such as practical Byzantinefault tolerance (PBFT), a node with accounting rights can bepredetermined before the current round of accounting. Therefore, afterreceiving the data acquisition transaction, the blockchain node can sendthe data acquisition transaction to the accounting node if theblockchain node itself is not the accounting node of the current round.The accounting node of the current round (which can be the previousblockchain node) can execute the data acquisition transaction when orbefore packing the data acquisition transaction to generate a new blockor when or before packing the data acquisition transaction with othertransactions to generate a new block. The accounting node packs the dataacquisition transaction (or packs the data acquisition transaction withother transactions) to generate a new block, and then sends the newblock generated or a block header to other nodes for consensus.

As described above, in the blockchain network using the POW mechanism orin the blockchain network using POS, DPOS, and PBFT mechanisms, theaccounting node of the current round can pack the data acquisitiontransaction to generate a new block, and send the new block generated ora block header to other nodes for consensus. If the other nodes verifythat there is no problem after receiving the block, the new block can beappended to the end of an original blockchain, so that the accountingprocess is completed and a consensus is reached. If the data acquisitiontransaction is used to invoke a data authorization smart contract,invocation and execution of the data authorization smart contract arecompleted. When performing verification on a new block or a block headersent by the accounting node, another node can also execute a dataacquisition transaction in the block.

Step 304: The blockchain node executes a data authorization smartcontract invoked to perform the data acquisition transaction, where thedata authorization smart contract is used to obtain the target data whenit is confirmed that the data user is authorized, so that the data userobtains at least one of the target data and an operation result obtainedafter a predetermined operation is performed on the target data.

After the data authorization smart contract is created, a correspondingcontract account is formed in the blockchain, and the contract accounthas a specified contract address. For example, the data acquisitiontransaction can include the contract address in a TO field of the dataacquisition transaction to invoke the data authorization smart contract.As described above, after blockchain nodes in the blockchain networkreach a consensus, each node receives the data acquisition transaction,reads the TO field of the data acquisition transaction, and invokes thedata authorization smart contract, which specifically means reading codeof the data authorization smart contract into an EVM of the blockchainnode for execution.

The data acquisition transaction can include information about thetarget data, for example, a hash value or any other descriptioninformation of the target data, provided that the information can relateto the target data. For example, the information about the target datacan be included in a DATA field of the data acquisition transaction.When the data acquisition transaction invokes the data authorizationsmart contract, content in the DATA field can be used as inputinformation of the data authorization smart contract.

The data authorization smart contract can include a corresponding listof authorized parties for recording information about authorized objectsof data held by the data owner, namely, information about the authorizedparties. In this case, if the data authorization smart contract confirmsthat the data user is in the list of authorized parties, it can beconfirmed that the data user is authorized. In a management method ofthe list of authorized parties, one-time authorization can be performedon all data held by the data owner, and content of the list ofauthorized parties is not affected even when the data held by the dataowner increases or decreases, in other words, an update to the data heldby the data owner can be compatible.

When the data authorization smart contract is being created, informationabout the list of authorized parties can be written into contract code,so that content of the list of authorized parties cannot be changed. Inthis case, the data authorization smart contract may need to be replacedor a version thereof may need to be updated, to update the list ofauthorized parties. Or, the data authorization smart contract can haveone or more corresponding states, and the blockchain node can maintainvalues of the one or more states. When a state value is informationabout an authorized party, the one or more states are equivalent to thelist of authorized parties. The data owner can submit a blockchaintransaction in the blockchain network, and the blockchain transactioncan invoke an authorization interface defined in the data authorizationsmart contract, so that content of the list of authorized parties can beupdated after the data authorization smart contract is executed, withouta need to replace the data authorization smart contract or update aversion thereof. Or, the data authorization smart contract can invokeanother smart contract, and code or a state of the another smartcontract can be used to record the list of authorized parties. If thelist of authorized parties is immutably written into the code of theanother smart contract, when the list of authorized parties needs to beupdated, a new smart contract can be created, where code of the newsmart contract includes an updated list of authorized parties, and thenthe data authorization smart contract invokes a contract address of thenew smart contract (the invoked contract address can be used as a stateof the data authorization smart contract, and a value of the state canchange). If the list of authorized parties is written into the statecorresponding to the another smart contract, as described above, only avalue of the state needs to be updated, to update the list of authorizedparties, without a need to update the contract address invoked by thedata authorization smart contract. The contract address can bepermanently written into code of the data authorization smart contract,or can be written into a state of the data authorization smart contract.

The data user can temporarily request authorization from the data owner.For example, the data user can submit an authorization requesttransaction to the blockchain network, and the authorization requesttransaction invokes a request interface defined in the dataauthorization smart contract. As such, after executing the authorizationrequest transaction, the blockchain node can invoke the requestinterface defined in the data authorization smart contract, so that thedata authorization smart contract writes an authorization request eventinto a transaction log. Then, through an event monitoring respondingmechanism, the data owner can respond to the authorization request eventwritten into the transaction log. For example, when it is determinedthat the data user can be authorized, the data owner can submit anauthorization confirmation transaction to the blockchain network, andthe authorization confirmation transaction invokes an authorizationinterface defined in the data authorization smart contract. As such,after executing the authorization confirmation transaction, theblockchain node can invoke the authorization interface defined in thedata authorization smart contract, so that the data authorization smartcontract marks the data user as authorized. In one situation where thedata user is marked as authorized, the data user can be added to thelist of authorized parties. A process of adding the data user to thelist of authorized parties is described above, and details are omittedhere for simplicity. Provided that the data user is in the list ofauthorized parties, the data user can request to obtain the data held bythe data owner at any time, in other words, the data user is authorizedin the long term. In the other situation, the data authorization smartcontract only confirms that the data user is authorized for a currentoperation, and the data authorization smart contract can respond to adata acquisition request of the data user this time. However, after acurrent data acquisition transaction is completed, the data user isunauthorized, and the data user needs to request authorization from thedata owner again.

Although the list of authorized parties belongs to long-termauthorization compared with the latter situation, the list of authorizedparties doesn't necessarily mean permanent authorization. For example,the data owner can update the list of authorized parties to remove oneor more authorized parties, so that the one or more authorized partiesare unauthorized. For another example, each authorized party in the listof authorized parties can have a certain quantity of remainingauthorization duration and/or the quantity of remaining authorizations.When the remaining authorization duration or the quantity of remainingauthorizations is reset to 0, a corresponding authorized party can beautomatically removed from the list of authorized parties, which isequivalent to an “aging” mechanism implemented on an authorized party inthe list of authorized parties.

The data user can include the information about the target data in theauthorization request transaction, and the information about the targetdata can be written into the authorization request event in thetransaction log, so that the data owner learns an authorization rangerequested by the data user. If the authorization request transactiondoes not include any data information, authorization for all data heldby the data owner is requested by the data user. Accordingly, the dataowner can add the information about the target data to the authorizationconfirmation transaction to indicate that the data user is authorizedfor the target data. If the authorization confirmation transactionsubmitted by the data owner does not include any data information, thedata owner authorizes the data user for all data. Therefore, in somesituations, the information about the target data included in the dataacquisition transaction of the data user can be inconsistent with anauthorization range (i.e., data that the data user is authorized)obtained by the data user. In this case, the data acquisitiontransaction may not be normally executed or the data authorization smartcontract cannot successfully obtain the target data specified in thedata acquisition transaction.

After the data authorization smart contract obtains the target data, thetarget data can be directly provided to the data user. For example, thedata authorization smart contract can write the target data into thetransaction log of the data acquisition transaction, so that the datauser can obtain the target data by monitoring the transaction log. Theblockchain node can encrypt the target data, so that encrypted targetdata is written into the transaction log. In this case, a data userholding a key can read and decrypt the encrypted target data to obtainthe target data, and an unrelated user cannot decrypt the encryptedtarget data. Therefore, it can be ensured that the data user obtains thetarget data, and the situation that target data is written into thetransaction log in plaintext and obtained by an unrelated person can beavoided. As such, leakage of the target data is alleviated, andinterests of the data owner are protected.

After obtaining the target data, the data authorization smart contractcan perform the predetermined operation on the target data, and providethe operation result to the data user. The predetermined operation canbe any operation desired by the data user, and is not limited in thepresent specification. For example, an operation rule of thepredetermined operation can be predefined in the data authorizationsmart contract. One or more operation rules can be defined in the dataauthorization smart contract. Especially, when there are a plurality ofoperation rules, the data user can specify a needed operation rule inthe data acquisition transaction (e.g., the data user adds an identifiercorresponding to the operation rule to the DATA field of the dataacquisition transaction). For another example, an operation rule of thepredetermined operation can be transferred into the data authorizationsmart contract by the data acquisition transaction. For example, theoperation rule of the predetermined operation can be written into theDATA field of the data acquisition transaction, and then transferredinto the data authorization smart contract. When the correspondingoperation result is obtained after the predetermined operation isperformed on the target data, if the data user cannot inversely deduce avalue of the target data from the operation result, the data user can beprevented from directly obtaining the target data while a dataacquisition requirement of the data user is satisfied. As such, the datauser can be prevented from leaking the target data and jeopardizinginterests of the data owner, ensuring that the target data is alwaysheld only by the data owner.

Data held by the data owner can have different privacy levels.Correspondingly, data at different privacy levels can be processed indifferent ways. For example, the data owner can separately hold data ata relatively low privacy level and data at a relatively high privacylevel. Correspondingly, when the target data is at the low privacylevel, the target data can be provided to the data user, in other words,the data owner does not care whether the data at the low privacy levelis leaked. When the target data is at the high privacy level, apredetermined operation needs to be performed on the target data, sothat a corresponding operation result is provided to the data user,ensuring that the data at the high privacy level is not leaked. If thetarget data includes both data at the low privacy level and data at thehigh privacy level, the target data at the low privacy level can bedirectly provided to the data user, the predetermined operation isperformed on the target data at the high privacy level, and theoperation result is then provided to the data user. Or, especially whenthe data user has specified a needed operation rule of the predeterminedoperation in the data acquisition transaction, the predeterminedoperation can be implemented on all target data, and then the operationresult is provided to the data user.

At least one of the target data and the operation result can be writteninto the transaction log by the data authorization smart contract usingan event mechanism. For example, a transaction execution result event isformed in the transaction log, so that the data user can monitor thetransaction execution result event to obtain at least one of the targetdata and the operation result. A rule of the monitoring process issimilar to that of monitoring the authorization request event by thedata owner. Therefore, details are omitted here for simplicity.

The target data can be stored in a database corresponding to theblockchain node, so that after the data authorization smart contract isexecuted, the target data can be directly read from the database andprovided to the data user. To prevent the target data from beingobtained by an unrelated person, the target data can be encrypted, andcorresponding encrypted target data is stored in the database, so thatthe unrelated person can only obtain the encrypted target data at most,thereby alleviating leakage of the target data.

The target data can be encrypted in a trusted execution environment(TEE). Because the target data can be any data requested by the datauser and held by the data owner, any data held by the data owner can beencrypted in a similar way. The TEE is a trusted execution environmentbased on a secure extension of CPU hardware that is isolated from theoutside. The TEE was first proposed by the Global Platform to alleviatea problem of resource security isolation on a mobile device, and isparallel to a trusted and secure execution environment provided by anoperating system to an application. For example, TEE technologies suchas Intel's Software Protection Extensions (SGX) isolate code execution,remote attestation, secure configuration, secure storage of data, andtrusted paths for executing code. Security of an application running inthe TEE is protected, and the application is almost impossible to beaccessed by a third party.

The Intel SGX technology is used as an example. The blockchain node canallocate an enclave page cache (EPC) in a memory by using a processorinstruction added to a CPU, load an EVM into the EPC, and confirm,through remote attestation, that code of the loaded EVM is consistentwith code of an EVM at a key management server (e.g., comparing hashvalues). After the remote attestation succeeds, the blockchain nodeencrypts the target data by using a memory encryption engine (MME) inthe CPU, and stores encrypted target data into the EPC. The encryptedcontent in the EPC can be decrypted to a plaintext only after enteringthe CPU. In the CPU, the target data in plaintext is encrypted to obtainthe encrypted target data, so as to be stored in the databasecorresponding to the blockchain node. In response to the dataacquisition transaction submitted by the data user, the blockchain nodecan execute the data authorization smart contract in the trustedexecution environment, to read the encrypted target data into thetrusted execution environment for decryption, and then the dataauthorization smart contract performs a predetermined operation on thetarget data. For example, after the remote attestation succeeds, theblockchain node separately encrypts the obtained encrypted target dataand the code of the data authorization smart contract by using the MMEin the CPU, and stores encrypted target data and encrypted code into theEPC. The encrypted content in the EPC can be decrypted only afterentering the CPU. In the CPU, the encrypted target data can be decryptedto the target data in plaintext, and a predetermined operation isperformed on the target data by executing the code of the dataauthorization smart contract. Therefore, encryption and decryption areperformed for the target data in the TEE, and the code of the dataauthorization smart contract is executed, so that a secure and reliableenvironment can be provided, and interference from external factors isreduced.

The blockchain node can encrypt the target data by using a symmetricencryption key. For example, the key can be sent by the key managementserver to the blockchain node. For another example, the key can beobtained through negotiation between blockchain nodes. Or, the key canbe an asymmetric encryption key. Implementations are not limited in thepresent specification. The key can be stored in a security enclavecreated on the blockchain node. For example, the security enclave can bea quoting enclave (QE) instead of an application enclave (AE).

The data owner can store the target data in a blockchain by submitting aprivate certificate transaction to the blockchain network. Transactioncontent of the privacy certificate transaction includes the target datain plaintext. However, the transaction content of the privacycertificate transaction can be encrypted by using a key, so that after ablock where the privacy certificate transaction is located is added tothe blockchain, the target data cannot be obtained by viewing thetransaction content of the privacy certificate transaction.Correspondingly, a key can be maintained in the trusted executionenvironment of the blockchain node, so that the blockchain node candecrypt the privacy certificate transaction in the trusted executionenvironment after receiving the privacy certificate transactionsubmitted by the data owner, to obtain the target data included in thetransaction content. The data owner can encrypt the transaction contentthrough symmetric encryption or asymmetric encryption. Implementationsare not limited in the present specification. The key can be generatedthrough negotiation between the blockchain node and the data owner; orthe key can be generated by the key management server and sent to thedata owner and the blockchain node.

The data owner can store the target data in a blockchain by submitting acertificate transaction to the blockchain network. Transaction contentof the certificate transaction can include at least one of creating andinvoking a smart contract, so that after receiving the certificatetransaction submitted by the data owner, the blockchain node can executethe corresponding transaction content in the trusted executionenvironment, for example, executing code of the smart contract thatneeds to be created, invoked, or created and invoked, to generate thetarget data. Further, the blockchain node can encrypt the target dataand store the encrypted target data in the database. Because the targetdata appears in plaintext only in the trusted execution environment, andappears in ciphertext in an environment other than the trusted executionenvironment, there is no need to worry about leakage of the target datain plaintext.

In addition to being stored in the database of the blockchain node, thetarget data can be stored through a channel off the blockchain by thedata owner, and the blockchain node stores only a digital digest of thetarget data. For example, the digital digest can be a hash value of thetarget data. In this case, the data authorization smart contract canobtain the target data from the channel off the blockchain by using across-chain technology, and provide at least one of the target data andthe operation result to the data user. An oracle-based cross-chaintechnology is used as an example: The data authorization smart contractcan invoke an oracle smart contract, so that the oracle smart contractobtains the target data from the channel off the blockchain, and thenthe data authorization smart contract can write the obtained target datainto the transaction log of the data acquisition transaction by usingthe event mechanism, and/or perform the predetermined operation on thetarget data and then write the operation result into the transaction logof the data acquisition transaction by using the event mechanism, sothat the data user can monitor the transaction log to obtain at leastone of the target data and the operation result.

It is worthwhile to note that “data” held by the data owner andrequested by the data user in the present specification should beunderstood as a generalized concept, for example, a value, a character,an image, audio, a video, code, a program, or a model (e.g., anartificial intelligence model). Implementations are not limited in thepresent specification.

FIG. 4 is a schematic diagram illustrating end-to-end data authorizationimplemented based on a blockchain network, according to an exampleimplementation. As shown in FIG. 4, assume that nodes such as N1, N2,N3, N4, and N5 exist in a blockchain network, and the blockchain networkcan be a consortium blockchain network composed of a service platformand several partners. For example, in a supply chain financial scenario,nodes such as N1, N2, N4, and N5 correspond to several supply chainfinancial enterprises directly or indirectly, node N3 corresponds to theservice platform, and a user can obtain, based on the service platform,target data of each supply chain financial enterprise or an operationresult obtained based on the target data. For another example, in aninvoice scenario, nodes such as N1, N2, N4, and N5 correspond to severalmerchants directly or indirectly, node N3 corresponds to the serviceplatform, and a user can obtain, based on the service platform, invoicesissued by the merchants, some information in the invoices, or anoperation result obtained based on the invoice information. Certainly,the technical solutions of the present specification can be furtherapplied to another scenario. Implementations are not limited in thepresent specification. For ease of understanding, the following uses thesupply chain financial scenario as an example for description.

Assume that user Ua wants to know an average asset amount of supplychain financial enterprises C1 and C2 for related purposes. However,asset amounts are data that needs to be kept confidential for theenterprises C1 and C2, and cannot be separately provided by theenterprises C1 and C2 to user Ua, and therefore, user Ua cannotcalculate the average asset amount. According to the technical solutionsof the present specification, data privacy of the enterprises C1 and C2is not exposed, and interests of a data user (e.g., user Ua) and a dataowner (e.g., the enterprises C1 and C2) are protected while a dataacquisition requirement of user Ua is satisfied. For example, FIG. 5 isan interaction flowchart illustrating end-to-end data authorizationimplemented based on a blockchain network, according to an exampleimplementation. As shown in FIG. 5, an interaction procedure betweenuser Ua, a blockchain node, and enterprises C1 and C2 can include thefollowing steps:

Step 501: User Ua generates an authorization request transaction andsubmits the authorization request transaction to a blockchain network.

A computing device used by user Ua can run a client, generate theauthorization request transaction based on the client, and submit theauthorization request transaction to the blockchain network. Or, aftergenerating the authorization request transaction on a client, user Uacan upload the authorization request transaction to a service platform40, and the service platform 40 submits the authorization requesttransaction to the blockchain network. Or, user Ua can initiate anauthorization request to a service platform 40, so that the serviceplatform 40 generates the authorization request transaction and submitsthe authorization request transaction to the blockchain network.

The purpose of submitting the authorization request transaction to theblockchain network is to request the enterprises C1 and C2 to grant arelated right to user Ua, so that user Ua can finally obtain thepreviously described average asset amount. The authorization requesttransaction can include data description information describing datathat user Ua hopes to separately request authorization from theenterprises C1 and C2. For example, the data description information canseparately describe an asset amount of enterprise C1 and an asset amountof enterprise C2. Accordingly, user Ua can be authorized for the assetamount of enterprise C1 and the asset amount of enterprise C2, but isunauthorized for other data. Or, the authorization request transactionmay not include data description information, to indicate that user Uahopes to separately request to obtain authorization for all data fromthe enterprises C1 and C2, so that user Ua is authorized for all dataheld by the enterprises C1 and C2, including the previously describedasset amounts. The following describes subsequent steps by using anexample that the authorization request transaction includes the datadescription information.

The authorization request transaction is originally submitted to acertain node in the blockchain network. For example, when the serviceplatform 40 has a corresponding node N3 in the blockchain network, theauthorization request transaction can be usually submitted to node N3 bythe service platform 40, and certainly can also be submitted to othernodes. Similarly, the computing device used by user Ua can submit theauthorization request transaction to a certain node. After theauthorization request transaction is submitted to the blockchainnetwork, a consensus can be made between nodes, and an agreedauthorization request transaction can be executed on each node. POW,POS, DPOS, PBFT, or another consensus mechanism in a related technologycan be used in the consensus process. Implementations are not limited inthe present specification.

Step 502: The blockchain node assists, by invoking a request interfaceof smart contract T1, user Ua in obtaining data authorization, andwrites an authorization request event into a transaction log.

After the consensus, each node in the blockchain network needs toexecute the authorization request transaction. When executing theauthorization request transaction, the blockchain node reads an accountaddress filled in a TO field of the authorization request transaction,to invoke smart contract T1. Code of smart contract T1 can logicallygenerate a plurality of interfaces to implement different functions, andthe authorization request transaction can specifically specify aninterface that needs to be invoked. For example, when the authorizationrequest transaction invokes the request interface of smart contract T1,related authorization can be requested.

For example, the authorization request transaction can include thepreviously described data description information, information aboutuser Ua (e.g., a signature of user Ua), information about theenterprises C1 and C2 (e.g., public keys of the enterprises C1 and C2),etc., so that after the request interface of smart contract T1 isinvoked, the authorization request event can be written into thetransaction log of the authorization request transaction. Content of theauthorization request event can include the data descriptioninformation, the information about user Ua, the information about theenterprises C1 and C2, etc., to indicate that user Ua hopes to obtaintarget data corresponding to the data description information from theenterprises C1 and C2.

Step 503: The enterprises C1 and C2 monitor the authorization requestevent.

Because operations of blockchain nodes are consistent, the enterprisesC1 and C2 can access any corresponding blockchain node to learn theauthorization request event based on an event monitoring respondingmechanism, so as to determine the target data that user Ua hopes toobtain from the enterprises C1 and C2.

Step 504: The enterprises C1 and C2 separately generate authorizationrequest transactions and submit the authorization request transactionsto the blockchain network.

When allowing user Ua to obtain related target data, the enterprises C1and C2 can separately generate and submit the authorization confirmationtransactions, to indicate that the enterprises C1 and C2 agree toprovide the target data such as the asset amounts to user Ua. EnterpriseC1 is used as an example: The authorization confirmation transactiongenerated by enterprise C1 can include data description informationcorresponding to target data that enterprise C1 agrees to provide touser Ua, a public key of user Ua, a signature of enterprise C1, etc. Or,the authorization confirmation transaction can include information suchas a transaction number of the authorization request transaction, toindicate that enterprise C1 agrees a related request of theauthorization request transaction.

Step 505: The blockchain node invokes an authorization interface ofsmart contract T1, updates an authorization state of user Ua, and writesan authorization state update event into a transaction log.

As described above, smart contract T1 includes several predefinedinterfaces. In authorization confirmation transaction 1 submitted byenterprise C1 and authorization confirmation transaction 2 submitted byenterprise C2, TO fields can separately include a contract address ofsmart contract T1, and can specify a wish to invoke the authorizationinterface. Smart contract T1 can confirm, by running code correspondingto the authorization interface, that the enterprises C1 and C2separately agree to grant a right to user Ua for the target data such asthe asset amounts, so as to update the authorization state of user Ua to“authorized”. As described above, the authorized state of user Ua can berecorded in a plurality of forms, which depends on a rule defined insmart contract T1. Details are omitted here for simplicity.

For the update of the authorization state of user Ua, smart contract T1can write the corresponding authorization state update event into thetransaction log to indicate that user Ua has obtained authorization forthe asset amounts of the enterprises C1 and C2.

Step 506: User Ua monitors the authorization state update event.

Similar to step 503, user Ua can monitor, based on the event monitoringresponding mechanism, the transaction log in the blockchain node thatcorresponds to the authorization confirmation transactions, anddetermine, based on the detected authorization state update event, thatuser Ua has obtained authorization for asset amounts of the enterprisesC1 and C2.

Step 507: User Ua generates a data acquisition transaction and submitsthe data acquisition transaction to the blockchain network.

Similar to the authorization request transaction, user Ua can generateand submit the data acquisition transaction in a plurality of ways. Forexample, user Ua independently generates and submits the dataacquisition transaction, user Ua independently generates the dataacquisition transaction and then the service platform submits the dataacquisition transaction, or the service platform generates and submitsthe data acquisition transaction. Details are omitted here forsimplicity.

The data acquisition transaction can include data descriptioninformation describing that user Ua hopes to obtain the average assetamount of the enterprises C1 and C2 (which can specifically include datadescription information of the asset amounts of the enterprises C1 andC2 and indicate that an operation rule used is averaging). Or, the dataacquisition transaction can include the transaction number of theauthorization request transaction or a transaction number of theauthorization confirmation transaction, and can also indirectly indicatethat user Ua hopes to obtain the average asset amount of the enterprisesC1 and C2.

Step 508: The blockchain node invokes a data interface of smart contractT1, and writes a transaction execution result event into a transactionlog.

The data interface of smart contract T1 is invoked to indicate, to smartcontract T1, that user Ua hopes to obtain the average asset amount ofthe enterprises C1 and C2. Smart contract T1 can search for theauthorization state of user Ua.

If user Ua is unauthorized, the transaction can be terminated. Or, smartcontract T1 can write the authorization request event into thetransaction log, to temporarily request authorization from theenterprises C1 and the enterprise C2 through a process similar to steps502 to 505. In this case, the data acquisition transaction is equivalentto an authorization request function and a data acquisition function,and a related operation and step of the authorization requesttransaction can be omitted.

If user Ua has been authorized, smart contract T1 can obtain the assetamounts of the enterprises C1 and C2. For example, when values of theasset amounts are stored in the blockchain, for example, stored in theblockchain in ciphertext, smart contract T1 can read encrypted assetamounts and decrypt the asset amounts in the trusted executionenvironment at the blockchain node to obtain the asset amounts inplaintext. For another example, when values of the asset amounts arestored through channels off the blockchain separately maintained by theenterprises C1 and C2, smart contract T1 can obtain the values of theasset amounts by using a cross-chain technology. For example, smartcontract T1 can invoke oracle smart contract T2, so that oracle smartcontract T2 can separately read the asset amounts of the enterprises C1and C2 from the channels off the blockchain, and return the assetamounts to smart contract T1.

After obtaining the asset amounts of the enterprises C1 and C2, smartcontract T1 can calculate the corresponding average asset amount basedon a predefined operation rule. For example, when the asset amount ofenterprise C1 is m1 and the asset amount of enterprise C2 is m2, theaverage asset amount can be calculated as follows: M=(m1+m2)/2.Correspondingly, smart contract T1 can add the value of the averageasset amount M to the transaction execution result event, and write thetransaction execution result event into the transaction log of the dataacquisition transaction.

Step 509: User Ua monitors the transaction execution result event.

As described above, user Ua can monitor the transaction log of the dataacquisition transaction based on the event monitoring respondingmechanism, to detect the transaction execution result event. If the dataacquisition transaction is successfully implemented, user Ua can obtainthe average asset amount M of the enterprises C1 and C2 from thetransaction execution result event, so that a requirement of user Ua onthe average asset amount can be satisfied, and leakage of the values ofthe asset amounts of the enterprises C1 and C2 can be alleviated.

FIG. 6 is a schematic structural diagram illustrating a device,according to an example implementation. As shown in FIG. 6, in terms ofhardware, the device includes a processor 602, an internal bus 604, anetwork interface 606, a memory 608, and a non-volatile memory 610, andcertainly can further include other hardware needed by services. Theprocessor 602 reads a corresponding computer program from thenon-volatile memory 610 into the memory 608 and then runs thecorresponding computer program, so as to form a smart contract-baseddata authorization apparatus in terms of logic. Certainly, in additionto software implementation, one or more implementations of the presentspecification do not exclude other implementations, for example, alogical device or a combination of hardware and software. In otherwords, an execution body of the following processing procedure is notlimited to each logical unit, and can also be hardware or a logicaldevice.

As shown in FIG. 7, in terms of software implementation, the smartcontract-based data authorization apparatus can include the following: areceiving unit 701, configured to enable a blockchain node to receive adata acquisition transaction submitted by a data user, where the dataacquisition transaction is used to request to obtain target data held bya data owner; and an execution unit 702, configured to enable theblockchain node to execute a data authorization smart contract invokedto perform the data acquisition transaction, where the dataauthorization smart contract is used to obtain the target data when itis confirmed that the data user is authorized, so that the data userobtains at least one of the target data and an operation result obtainedafter a predetermined operation is performed on the target data.

Optionally, the data authorization smart contract has a correspondinglist of authorized parties, and it is confirmed that the data user isauthorized when the data authorization smart contract confirms that thedata user is in the list of authorized parties.

Optionally, the apparatus further includes the following: anauthorization request unit 703, configured to enable the blockchain nodeto invoke a request interface defined in the data authorization smartcontract based on an authorization request transaction submitted by thedata user, so that the data authorization smart contract writes anauthorization request event into a transaction log for monitoring by thedata owner; and an authorization confirmation unit 704, configured toenable the blockchain node to invoke an authorization interface definedin the data authorization smart contract based on an authorizationconfirmation transaction submitted by the data owner, so that the dataauthorization smart contract marks the data user as authorized.

Optionally, when the target data is at a low privacy level, the targetdata is provided to the data user; or when the target data is at a highprivacy level, the predetermined operation is performed on the targetdata, so that the corresponding operation result is provided to the datauser.

Optionally, an operation rule of the predetermined operation ispredefined in the data authorization smart contract; or an operationrule of the predetermined operation is transferred into the dataauthorization smart contract by the data acquisition transaction.

Optionally, at least one of the target data and the operation result iswritten into a transaction execution result event in a transaction logby the data authorization smart contract, so that the data user performsmonitoring and acquisition.

Optionally, the apparatus further includes the following: a dataencryption unit 705, configured to enable the blockchain node to encryptthe target data in a trusted execution environment to obtain encryptedtarget data, so that the encrypted target data is stored in a databasecorresponding to the blockchain node; and a data operation unit 706,configured to enable the blockchain node to execute the dataauthorization smart contract in the trusted execution environment, sothat the data authorization smart contract performs the predeterminedoperation after the encrypted target data is read into the trustedexecution environment and decrypted.

Optionally, the apparatus further includes the following: a transactiondecryption unit 707, configured to enable the blockchain node todecrypt, after receiving a privacy certificate transaction submitted bythe data owner, the privacy certificate transaction in the trustedexecution environment to obtain the target data included in transactioncontent; or a data generation unit 708, configured to enable theblockchain node to execute, after receiving a certificate transactionsubmitted by the data owner, corresponding transaction content in thetrusted execution environment to generate the target data.

Optionally, the blockchain node stores a digital digest of the targetdata, the target data is stored through a channel off the blockchain bythe data owner, and the data authorization smart contract invokes anoracle smart contract, so that the oracle smart contract obtains thetarget data from the channel off the blockchain, and the dataauthorization smart contract performs the predetermined operation.

The system, apparatus, module, or unit illustrated in the previousimplementations can be specifically implemented by using a computer chipor an entity, or can be implemented by using a product having a certainfunction. A typical implementation device is a computer, and thecomputer can be specifically a personal computer, a laptop computer, acellular phone, a camera phone, a smartphone, a personal digitalassistant, a media player, a navigation device, an email receiving andsending device, a game console, a tablet, a wearable device, or anycombination of these devices.

In a typical configuration, a computer includes one or more processors(CPU), an input/output interface, a network interface, and a memory.

The memory can include a non-persistent memory, a random access memory(RAM), a non-volatile memory, and/or another form that are in a computerreadable medium, for example, a read-only memory (ROM) or a flash memory(flash RAM). The memory is an example of the computer readable medium.

The computer readable medium includes persistent, non-persistent,movable, and unmovable media that can store information by using anymethod or technology. The information can be a computer readableinstruction, a data structure, a program module, or other data. Examplesof a computer storage medium include but are not limited to a phasechange random access memory (PRAM), a static RAM (SRAM), a dynamic RAM(DRAM), a RAM of another type, a read-only memory (ROM), an electricallyerasable programmable ROM (EEPROM), a flash memory or another memorytechnology, a compact disc ROM (CD-ROM), a digital versatile disc (DVD)or another optical storage, a cassette tape, a magnetic disk storage, aquantum memory, a storage medium based on grapheme, another magneticstorage device, or any other non-transmission medium. The computerstorage medium can be used to store information that can be accessed bythe computing device. Based on the definition in the presentspecification, the computer readable medium does not include transitorymedia such as a modulated data signal and carrier.

It is worthwhile to further note that, the terms “include”, “contain”,or their any other variants are intended to cover a non-exclusiveinclusion, so a process, a method, a product or a device that includes alist of elements not only includes those elements but also includesother elements which are not expressly listed, or further includeselements inherent to such process, method, product or device. Withoutmore constraints, an element preceded by “includes a . . . ” does notpreclude the existence of additional identical elements in the process,method, product or device that includes the element.

Specific implementations of the present specification are describedabove. Other implementations fall within the scope of the appendedclaims. In some situations, the actions or steps described in the claimscan be performed in an order different from the order in theimplementations and the desired results can still be achieved. Inaddition, the process depicted in the accompanying drawings does notnecessarily need a particular execution order to achieve the desiredresults. In some implementations, multi-tasking and concurrentprocessing is feasible or can be advantageous.

Terms used in one or more implementations of the present specificationare merely used to describe specific implementations, and are notintended to limit the one or more implementations of the presentspecification. The terms “a” and “the” of singular forms used in one ormore implementations of the present specification and the appendedclaims are also intended to include plural forms, unless otherwisespecified in the context clearly. It should be further understood thatthe term “and/or” used in the present specification indicates andincludes any or all possible combinations of one or more associatedlisted items.

It should be understood that although terms “first”, “second”, “third”,etc. can be used in one or more implementations of the presentspecification to describe various types of information, the informationis not limited to these terms. These terms are only used todifferentiate between information of the same type. For example, withoutdeparting from the scope of one or more implementations of the presentspecification, first information can also be referred to as secondinformation, and similarly, the second information can be referred to asthe first information. Depending on the context, for example, the word“if” used here can be explained as “while”, “when”, or “in response todetermining”.

The previous descriptions are only example implementations of one ormore implementations of the present specification, but are not intendedto limit the one or more implementations of the present specification.Any modification, equivalent replacement, improvement, etc. made withoutdeparting from the spirit and principle of the one or moreimplementations of the present specification shall fall within theprotection scope of the one or more implementations of the presentspecification.

1.-20. (canceled)
 21. A blockchain-based data authorization method,comprising: receiving, by a blockchain node, a data acquisitiontransaction submitted by a data user for obtaining target data possessedby a data owner; transmitting, by the blockchain node, the dataacquisition transaction to a second blockchain node based on ablockchain consensus process; determining, by the blockchain node, thatthe data user has obtained authorization of the target data; executing,by the blockchain node, a smart contract invoked by the data acquisitiontransaction to provide one or more of the target data and acomputational result of one or more predetermined computationaloperations performed based on the target data to the data user; andproviding, by the blockchain node and based at least on the blockchainnode and the second blockchain node executing the smart contract, thetarget data and the computational result to the data user, wherein atransaction execution result event based on the target data and thecomputational result are written in a transaction log by the smartcontract, and wherein the transaction log is monitored and available tobe acquired by the data user.
 22. The method according to claim 11,wherein the smart contract comprises a list of authorized usersincluding the data user and the determining that the data user hasobtained authorization of the target data is performed based on the listof authorized users.
 23. The method according to claim 21, furthercomprising: invoking, by the blockchain node, a request interfacedefined in the smart contract based on an authorization requesttransaction submitted by the data user to cause the smart contract towrite an authorization request event into the transaction log of thedata owner; and invoking, by the blockchain node, an authorizationinterface defined in the smart contract based on an authorizationconfirmation transaction submitted by the data owner to cause the smartcontract to mark the data user as an authorized user.
 24. The methodaccording to claim 21, wherein the smart contract is executed to providethe target data to the data user if the target data has low data privacylevel; and the smart contract is executed to provide the computationalresult of the one or more predetermined computational operations if thetarget data has high data privacy level.
 25. The method according toclaim 21, wherein one or more operation rules of the one or morepredetermined computational operations are predefined in the smartcontract or are transferred into the smart contract through the dataacquisition transaction.
 26. The method according to claim 21, whereinproviding, by the blockchain node and based on, at least, the blockchainnode and the second blockchain node executing the smart contract, thetarget data and the computational result to the data user comprises:encrypting the target data and the computational result; and storing theencrypted target data and the encrypted computational result within thetransaction execution result event in the transaction log, wherein theencrypted target data and the encrypted computational result areconfigured to enable the data user to decrypt the encrypted target dataand the encrypted computational result to obtain the target data and thecomputational result.
 27. The method according to claim 21, furthercomprising: encrypting, by the blockchain node, the target data in atrusted execution environment (TEE) to obtain encrypted target data;storing, by the blockchain node, the encrypted target data to a databaseassociated with the blockchain node; and wherein the executing the smartcontract is performed in the TEE after reading the encrypted target datainto the TEE and decrypting the encrypted target data.
 28. The methodaccording to claim 27, wherein the data acquisition transaction is acyphertext of a privacy depository transaction, and executing the smartcontract further comprises: decrypting, by the blockchain node thecyphertext in the TEE to obtain the target data.
 29. The methodaccording to claim 21, wherein the blockchain node stores a digitaldigest of the target data, the target data is stored by the data ownerin a storage media other than a blockchain of the blockchain node, andis retrieved by another smart contract from the storage media andtransferred to the smart contract to perform the one or morepredetermined computational operations.
 30. A computer-implementedsystem, comprising: one or more computers, and one or more computermemory devices interoperably coupled with the one or more computers andhaving tangible, non-transitory, machine-readable media storing one ormore instructions that, when executed by the one or more computers,perform operations comprising: receiving, by a blockchain node, a dataacquisition transaction submitted by a data user for obtaining targetdata possessed by a data owner; transmitting, by the blockchain node,the data acquisition transaction to a second blockchain node based on ablockchain consensus process; determining, by the blockchain node, thatthe data user has obtained authorization of the target data; executing,by the blockchain node, a smart contract invoked by the data acquisitiontransaction to provide one or more of the target data and acomputational result of one or more predetermined computationaloperations performed based on the target data to the data user; andproviding, by the blockchain node and based at least on the blockchainnode and the second blockchain node executing the smart contract, thetarget data and the computational result to the data user, wherein atransaction execution result event based on the target data and thecomputational result are written in a transaction log by the smartcontract, and wherein the transaction log is monitored and available tobe acquired by the data user.
 31. The computer-implemented systemaccording to claim 30, wherein the smart contract comprises a list ofauthorized users including the data user and the determining that thedata user has obtained authorization of the target data is performedbased on the list of authorized users.
 32. The computer-implementedsystem according to claim 30, further comprising: invoking, by theblockchain node, a request interface defined in the smart contract basedon an authorization request transaction submitted by the data user tocause the smart contract to write an authorization request event intothe transaction log of the data owner; and invoking, by the blockchainnode, an authorization interface defined in the smart contract based onan authorization confirmation transaction submitted by the data owner tocause the smart contract to mark the data user as an authorized user.33. The computer-implemented system according to claim 30, wherein thesmart contract is executed to provide the target data to the data userif the target data has low data privacy level; and the smart contract isexecuted to provide the computational result of the one or morepredetermined computational operations if the target data has high dataprivacy level.
 34. The computer-implemented system according to claim30, wherein one or more operation rules of the one or more predeterminedcomputational operations are predefined in the smart contract or aretransferred into the smart contract through the data acquisitiontransaction.
 35. The computer-implemented system according to claim 30,wherein providing, by the blockchain node and based on, at least, theblockchain node and the second blockchain node executing the smartcontract, the target data and the computational result to the data usercomprises: encrypting the target data and the computational result; andstoring the encrypted target data and the encrypted computational resultwithin the transaction execution result event in the transaction log,wherein the encrypted target data and the encrypted computational resultare configured to enable the data user to decrypt the encrypted targetdata and the encrypted computational result to obtain the target dataand the computational result.
 36. The computer-implemented systemaccording to claim 30, further comprising: encrypting, by the blockchainnode, the target data in a trusted execution environment (TEE) to obtainencrypted target data; storing, by the blockchain node, the encryptedtarget data to a database associated with the blockchain node; andwherein the executing the smart contract is performed in the TEE afterreading the encrypted target data into the TEE and decrypting theencrypted target data.
 37. The computer-implemented system according toclaim 36, wherein the data acquisition transaction is a cyphertext of aprivacy depository transaction, and executing the smart contract furthercomprises: decrypting, by the blockchain node the cyphertext in the TEEto obtain the target data.
 38. The computer-implemented system accordingto claim 30, wherein the blockchain node stores a digital digest of thetarget data, the target data is stored by the data owner in a storagemedia other than a blockchain of the blockchain node, and is retrievedby another smart contract from the storage media and transferred to thesmart contract to perform the one or more predetermined computationaloperations.
 39. A non-transitory, computer-readable medium storing oneor more instructions executable by a computer system to performoperations comprising: receiving, by a blockchain node, a dataacquisition transaction submitted by a data user for obtaining targetdata possessed by a data owner; transmitting, by the blockchain node,the data acquisition transaction to a second blockchain node based on ablockchain consensus process; determining, by the blockchain node, thatthe data user has obtained authorization of the target data; executing,by the blockchain node, a smart contract invoked by the data acquisitiontransaction to provide one or more of the target data and acomputational result of one or more predetermined computationaloperations performed based on the target data to the data user; andproviding, by the blockchain node and based at least on the blockchainnode and the second blockchain node executing the smart contract, thetarget data and the computational result to the data user, wherein atransaction execution result event based on the target data and thecomputational result are written in a transaction log by the smartcontract, and wherein the transaction log is monitored and available tobe acquired by the data user.
 40. The non-transitory, computer-readablemedium of claim 39, wherein the smart contract comprises a list ofauthorized users including the data user and the determining that thedata user has obtained authorization of the target data is performedbased on the list of authorized users.